Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/networking/terms/kermit/e/v14.1

Internet Message Format | 1991-07-26 | 12.3 KB

From cmg  Tue Jul  9 16:33:19 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA24985; Tue, 9 Jul 91 16:33:19 EDT
Date: Tue, 9 Jul 91 16:33:17 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #1
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 9 Jul 1991        Volume 14 : Number 1

Today's Topics:

           New VT200/300 Key Mapping File for MS-DOS Kermit
           MS-DOS Kermit and Microsoft Windows 3.0
                 Kermit and Desqview
              Kermit, LAT & Windows 3.0 problem
           8-bit Linemode Devices on IBM Mainframes
              New VMSHEX/VMSDEH Programs


Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV).  To order by mail, request a
complete list of Kermit versions and an order form from Kermit Distribution,
Columbia University Center for Computing Activities, 612 West 115th Street,
New York, NY 10025 USA.

----------------------------------------------------------------------

Date: Thu, 20 Jun 1991 10:58 CST
>From: Kevin Lowey <[e-mail]>
Subject: New VT200/300 Key Mapping File for MS-DOS Kermit
Keywords: MS-DOS Kermit

Here is a new version of MSIVT3.INI (also known as VT300.INI) which fixes a
bug in the extended keyboard definition, in which the DEC Remove key was
mapped to a nonexistent scan code, rather than to Gray Delete.  Also, the PC
F11 and F12 keys on extended keyboards are now used for Help and Do,
respectively, and the DEC F11-F20 keys are now mapped to Alt-F1 through
Alt-F10 on both 88 and 101 keyboards, for consistency, and the DEC Enter key
was moved to PC F10 on the 88 keyboard to make it easier to use programs
that require the keypad Enter key.

[Ed. - Thanks, Kevin.  The new file replaces the old version as msivt3.ini.
The documentation file, msivt3.doc, has also been updated.]

------------------------------

Date: Tue,  25 Jun 1991 14:25:32 EDT
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit and Microsoft Windows 3.0
Keywords: MS-DOS Kermit, Microsoft Windows, Windows

In response to numerous queries, here is the situation -- as best we know it
-- with MS-DOS and Microsoft Windows.

MS-DOS Kermit is not a "Windows Application".  It was not written
specifically for Windows, and it does not have a Windows-like menu-and-mouse
command interface.  However, MS-DOS Kermit has knowledge of the Windows
environment and can run "in a window" under certain conditions.  This means
that Kermit can run simultaneously with other Windows applications (even
other copies of Kermit), it can use Windows fonts, and you can cut and paste
to and from the Kermit window into other windows, etc, if you have
constructed the KERMIT.PIF file properly and you have enough memory for
Kermit.

When Kermit cannot be run in a Window, you can still use it under Windows as
a full-screen application.

Under Windows 2.0, you can use Kermit in a window on any kind of PC or PS/2
that has enough memory.  Everything works normally (but slower) except
Tektronix emulation, which behaves as if you had a monochrome video adapter
(plus signs are used instead of dots).  The important .PIF file parameters
are "Directly Modifies" (uncheck all the boxes), "Memory Requirements" (190
KB required, 400 KB desired), "Program Switch" (check Text box), "Screen
Exchange" (check Text/Graphics box).  If you don't have enough memory, you
can reduce Kermit's memory requirement by eliminating rollback screens: give
the DOS command "SET KERMIT=ROLLBACK 0" before starting Kermit, or put this
command into your MSKERMIT.INI file.

Under Windows 3.0, the situation is the same as for 2.0 if you are running
Windows on a 386 or 486 class PC in Enhanced Mode, with the added benefit
that Tektronix graphics works if you set up your KERMIT.PIF file for the
High Grahics Video Memory display option (however, Windows will complain
when you try to switch back to Kermit's text screen from the graphics
screen, and does not save the graphics screen).

However, Windows 3.0 apparently does not allow non-Windows DOS applications
(even Kermit, which is written with "Windows awareness") to operate in a
window in Real or Standard mode, which you must use on a 286 or lower class
PC, such as a PC, PC/XT, PC/AT, PS/2 Model 50, etc.  On these machines,
Windows 3.0 only allows Kermit to run in full-screen mode.  This seems to be
a limitation of Windows 3.0.  If anybody knows how to overcome this
limitation, please send mail about it to Info-Kermit.

If you can get Kermit into a window, but it does not communicate over the
COM1 or COM2 port, check your WIN.INI file to make sure that the MODE
command for COM1 or COM2 does not include a ",P" -- if it does, remove the
",P".

------------------------------

Date: Mon, 3 Jun 91 11:47:02 EDT
>From: Isidore G Bendrihem <[e-mail]>
Subject: Kermit and Desqview
Keywords: MS-DOS Kermit, DesqView

I've been running kermit under Desqview 386 (QEMM 5.11 and DV 2.31) with no
problems.  I recently installed an upgrade from Quaterdeck (QEMM 5.13 and DV
2.33), and whenever I start kermit, after giving the "Press ?  for help"
message, it freezes my computer up.  I can't even get back to Desqview.  It
seems like kermit has taken control over the keyboard.  Any suggestions?

Configuration:

386sx, 4 MB
Chips & Technologies chip set
AMI BIOS
MS-DOS 4.01
Kermit 3.10 (I've tried both with patches and without them)

[From jrd: What's one to say?  At the startup stage Kermit is using 100%
pure DOS calls to do everything. Kermit never grabs keyboard interrupts.
That leaves two possibilities: DV 2.33 has changed what needs to go into
your DV setup file for Kermit and/or DV 2.33 has problems.  MS-DOS Kermit
worked fine with the previous release of Quarterdeck software.]

------------------------------

Date: Tue, 4 Jun 1991 15:34:16 EDT
>From: [e-mail] (Maria Rosa Drake)
Subject: Kermit, LAT & Windows 3.0 problem
Keywords: MS-DOS Kermit, DEC Pathworks

We are running DECs PathWORKS network operating system, which provides LAT
support, and Kermit 3.01 and Kermit 3.10. We have no difficulty using Kermit
to access host systems via LAT when running under DOS; however we have
discovered that when invoking Kermit from within Windows 3.0 enhanced mode,
the system hangs (it works under Windows 3.0 standard mode).  Our
MSKERMIT.INI file does a SET PORT DECNET VAXname and a CONNECT; right after
connect is where the problems occur.

The systems are Zenith 386's with 4MB of RAM running either MS DOS 3.3+ or
MS DOS 4.0.  Any suggestions?

Maria Rosa Drake
Florida International University

[From jrd: One supposes that Pathworks is not designed to run by loading
DECnet outside Windows and then coupling a task to it within Windows.  At
least that's my guess.  The networking programs have to take some steps to
ensure the top level client is in the "right virtual machine" and so on, and
maybe your version of Pathworks does not do that job.  I make no pretense of
being a Windows 3.0 expert of any kind, but a suggestion is to start the
whole thing from a .BAT file within Windows, to see if that helps.  You
might also contact DEC to see if this is a known problem and get any
workarounds.  In addition, I would check the Pathworks documentation on
suggestions configuring Windows (things to be said in SYSTEM.INI etc
regarding networks).  It could turn out that Windows 3 itself is the culprit
when programs use high numbered interrupts for communications (DEC LAT and
CTERM both require these things to talk to external terminal emulators).]

------------------------------

Date: Wed, 1991 Jun 12   19:28 EDT
>From: "John F. Chandler"   <[e-mail]>
Subject: 8-bit Linemode Devices on IBM Mainframes
Keywords: IBM Mainframe Kermit

I am looking for people who would be interested in trying out 8-bit-wide
file transfer through a new generation of front ends on IBM mainframes.  The
following is a list of configurations that I believe may support the new
8-bit-wide ASCII communications, but it is not by any means complete and not
necessarily accurate.  I'd be interested to hear from anyone who has
knowledge of these or other 8-bit devices for "LU1" communications.  Also,
as I said before, I'm looking for testers willing to try out a version of
Kermit that has been modified to take advantage of the 8-bit capabilities.
I can be reached at either

  <[e-mail]>
or
  <[e-mail]>

Thanks.  By the way, even if all you can tell me is that I have
misspelled something in the list, I would still like to hear from you.
By the way, I posted this message on the BITNET discussion group for IBM
protocol convertors (which was the closest thing I could find to the
subject), but got no substantive answers.  I also posted it on the IBM
mainframe Kermit developers discussion group with no better results.

  Maker      Model          Software

  Fibronics  K2000          KNET/MVS
  Fibronics  K200           KNET/MVS
  Fibronics  K310           KNET/MVS
  Intel      Fastpath       ACCES/MVS
  ?          ACC9315        ACCES/MVS
  ?          Eicon/MSDOS    PACKET/74
  Intel      Jupiter 1000   PACKET/74
  IBM        37x5           COMMPRO/NAS
  Amdahl     47x5           COMMPRO/NAS
  Renex      RPAD
  Netlink    SNA/Gate
  Netlink    3703
  Perle      350/SNA
  Telematics PCI 167
  Telematics PCI 1067

------------------------------

Date: Wed, 5 Jun 1991 19:30:29 EDT
>From: [e-mail] (Jeff Guerber)
Subject: New VMSHEX/VMSDEH Programs
Keywords: VMS hex/dehex programs

It was recently pointed out on the Info-VAX mailing list that VMSHEX/VMSDEH
do not work for VAX indexed files -- they come out sequential instead.  I
took a look at the MACRO source, and it wasn't hard to find the bug -- the
file organization byte was not being saved in the hexified file, as were the
record format, record attributes, and so forth.  I have fixed the programs
(by adding a new packet type) so that they do save this byte, and they seem
to work as expected.  (I wasn't sure that they would, because the RMS manual
seems to indicate that extended attribute blocks are needed, but I
successfully hexed/dehexed an indexed file with 3 keys, and the new file
matched the original exactly.)  VMSDEH seems to work fine with older .HEX
files that don't have this packet, with the organization defaulting to
sequential as before.  A better method might be to save the entire file
access block and any extended attribute blocks, but this is beyond my
knowledge of MACRO and RMS.

If the Old VMSDEH is used on new-VMSHEXed files, the old VMSDEH gives an
"Unknown block type" error message, skips the new record and goes on to
do the rest of the input file, creating a sequential output file, and so
it appears that replacing the old VMSHEX/VMSDEH programs with the new ones
will do no harm.

Sorry, but I cannot take over support for these programs (if such is
needed); I really know very little about MACRO.

Jeff Guerber
ST Systems Corp. (STX)
NASA / Goddard, code 693.2
[e-mail]

Any opinions are my own and not those of NASA or STX.

[Ed. - Thanks, Jeff!  The new VMSHEX and VMSDEH programs have been placed
in the Kermit Test area for now.  If anybody encounters problems with them,
please send reports to Info-Kermit.  For that matter, if anyone can verify
that they do work as advertised, and are upwards compatible with the old
VMSHEX and VMSDEH programs, let us know.]

------------------------------

End of Info-Kermit Digest
*************************